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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Smart Card Platform (SCP). 

The contents of the present document are subject to continuing work within TC SCP and may change following formal 
TC SCP approval. If TC SCP modifies the contents of the present document, it will then be republished by ETSI with 
an identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

early working draft; 

1 presented to TC SCP for information; 

2 presented to TC SCP for approval; 

3 or greater indicates TC SCP approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document defines a communication interface between the UICC and a contactless frontend (CLF) in the 
terminal. This interface allows the card emulation mode independent of the power state of the terminal as well as the 
reader mode when the terminal is battery powered. 

The aim of the present document is to ensure interoperability between a UICC and the CLF in the terminal 
independently of the respective manufacturer, card issuer or operator. Any internal technical realization of either the 
UICC or the CLF is only specified where these are reflected over the interface. 
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1 Scope 

The present document specifies the Single Wire Protocol (SWP). SWF is the interface between the UICC and the CLF. 
The present document defines: 

• Layerl: The physical layer which is responsible for activating, maintaining and deactivating the physical link 
between the UICC and the CLF. It defines electrical (voltage and current levels, timing and coding of voltage 
and current levels), mechanical (physical connectors and wiring) and functional (data rates, max. transmission 
distances) specifications. It also defines the initial communication establishment and the end of the connection. 

• Layer 2: The data link layer which is responsible for the physical addressing of the data through frames and 
Link Protocol Data Unit (LPDU). The data link layer is also responsible for error notification, ordered delivery 
of frames and flow control. This layer can be split into two sub-layers: 

The Medium Access Control (MAC) layer which manages frames. 

The Logical Link Control layer which manages LPDU and is responsible for the error-free exchange of 
data between nodes. Three different Logical Link Control layers are defined in this specification. 



References 



References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the purposes 
of the referring document; 

for informative references. 

Referenced documents which are not found to be pubhcly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 221: "Smart Cards; UICC-Terminal interface; Physical and logical characteristics". 

[2] ISO/IEC 14443-2: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 2: Radio frequency power and signal interface". 

[3] ISO/IEC 14443-3: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 3: Initialization and anticollision". 
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[4] ISO/IEC 14443-4: "Identification cards - Contactless integrated circuit(s) cards - Proximity cards - 

Part 4: Transmission protocol". 

[5] ISO/lEC 13239: "Information technology - Telecommunications and information exchange 

between systems - High-level data link control (HDLC) procedures". 

[6] ETSI TS 102 600: "Smart Cards; UICC-Terminal interface; Characteristics of the USB interface". 

[7] ETSI TS 102 223: "Smart Cards; Card Application Toolkit (CAT)". 

[8] ISO/IEC 18092: "Information technology - Telecommunications and information exchange 

between systems - Near Field Communication - Interface and Protocol (NFCIP-1)". 



3 Definitions, symbols, abbreviations and coding 

conventions 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

card emulation mode: a mode where the UICC emulates a contactless card through the CLE 

class A operating conditions: terminal or a smart card operating at 5 V + 10 % 

class B operating conditions: terminal or a smart card operating at 3 V + 10 % 

class C operating conditions: terminal or a smart card operating at 1,8 V + 10 % 

contactless frontend: circuitry in the terminal which: 

• handles the analogue part of the contactless communication; 

• handles communication protocol layers of the contactless transmission link; 

• exchanges data with the UICC. 

full duplex: Simultaneous bidirectional data flow 

half duplex: Sequential bidirectional data flow 

idle bit: bit with logical value sent outside a frame in order to maintain signalling synchronization when no data are 
transmitted 

master: entity which provides the S 1 signal 

reader mode: mode where the UICC act as a contactless reader through the CLE 

state H: high electrical level of a signal (voltage or current) 

state L: low electrical level of a signal (voltage or current) 

SI: signal from the master to a slave 

S2: signal from the slave to the master 

slave: entity which is connected to the master and provides the S2 signal 

TS 102 221 interface: this term refers to the asynchronous serial UICC-Terminal interface defined in TS 102 221 [1], 
using RST on contact C2, CLK on contact C3 and I/O on contact C7 

UICC powering modes: 

• Full power mode: the UICC is powered according to TS 102 221 [1] limitations in operating state. 
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• Low power mode: the UICC is running in a reduced power mode as defined in the present specification. 
wakeup bit: first dummy bit transmitted by the master and/or the slave during a resume 



3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Gnd 



T 
T 



HI 
t'swp 

^UICC 



tR 

Vcc 

VlH 

V 



IL 
OH 



OL 



Ground 

Current signalling state H of S2 

Current signalling state L of S2 

Bit duration 

Duration of the state H for coding a logical 1 of S 1 

Duration of the state H for coding a logical of S 1 

Processing time of the CLF for a packet of data 

Transfer time of contactless command or response over the RF interface 

Transfer time a single S WP packet of date 

Processing time of the UICC for a contactless command 

Fall time 

Rise time 

Supply Voltage 

Input Voltage (high) 

Input Voltage (low) 

Output Voltage (high) 

Output Voltage (low) 



3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACT ACTivation protocol 

CLF ContactLess Frontend 

CLK CLocK 

CLT ContactLess Tunnelling protocol 

EOF End Of Frame 

HDLC High level Data Link Control 

I/O Input/Output 

ISO International Organization for Standardization 

LLC Logical Link Control 

LPDU Link Protocol Data Unit 

LSB Least Significant Bit 

MAC Medium Access Control 

MSB Most Significant Bit 

NFCIP-1 Near Field Communication - Interface and Protocol 

P2P Peer to Peer communication 

PCD Proximity Coupling Device 

PICC Proximity Integrated Circuit Card 

RFU Reserved for Future Use 

RST ReSeT 

SHDLC Simplified High Level Data Link Control 

SOF Start Of Frame 

SWIO Single Wire protocol Input/Output 

SWP Single Wire Protocol 

USB Universal Serial Bus 
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3.4 Coding conventions 

For the purposes of the present document, the following coding conventions apply: 

• all lengths are presented in bytes, unless otherwise stated. Each byte is represented by bits b8 to bl, where b8 
is the Most Significant Bit (MSB) and bl is the Least Significant Bit (LSB). In each representation, the 
leftmost bit is the MSB. 

• Hexadecimal values are enclosed in single quotes ('xx'). 

In the UICC, all bytes specified as RFU shall be set to '00' and all bits specifies as RFU shall be set to 0. 



Principle of the Single Wire Protocol 



The SWP interface is a bit oriented, point-to-point communication protocol between a UICC and a contactless frontend 
(CLF) as shown in figure 4. 1 . 



The CLF is the master and the UICC is the slave. 



S1 
CLF to UICC 



SWIG 
OUTPUT 



CLF 
(Master) 



Gnd 



S2 



S1 



SWIG 
INPUT 



UICC 
(Slave) 



Gnd 



S2 
UICC to CLF 

Figure 4.1 : SWP data transmission 

The principle of the Single Wire Protocol is based on the transmission of digital information in full duplex mode: 

• The signal S 1 is transmitted by a digital modulation (L or H) in the voltage domain. 

• The signal S2 is transmitted by a digital modulation (L or H) in the current domain. 

When the master sends SI as state H then the slave may either draw a current (state H) or not (state L) and thus transmit 
S2. With pulse width modulation bit coding of SI, it is possible to transmit a transmission clock, as well as data in full 
duplex mode. This bit coding of SI is described in clause 8.1 of the present document. S2 is meaningful only when SI 
is in state H. 
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System architecture 



5.1 



General overview 



Terminal 



Power 

supply 

i 



Coupling 
Coil 



o 



CLF 



C 



Vcc 



SWIG 



o 



Gnd 




UICC 



Figure 5.1 : CLF-UICC physical linlc 

Figure 5.1 represents the physical link between the CLF and the UICC. The contact C6 of the UICC is connected to the 
CLF for the transmission of S 1 and S2. 



5.2 TS 102 221 support 



A UICC supporting the SWP interface and a terminal supporting SWP shall remain compliant with TS 102 221 [1]. In 
order to maintain low power characteristics needed by some operating mode, a terminal supporting the SWP interface 
shall not support class A operating condition. 

For the low power mode, the electrical characteristics of contact CI (Vcc) are extended by the present document. 
Contacts C2, C3 and C7 shall behave as specified in TS 102 221 [1]. 



5.3 Configurations 



The terminal indicates the support of SWP interface in the terminal capability as defined in TS 102 221 [1]. The UICC 
indicates support of SWP interface in the Global Interface bytes of the ATR as defined in TS 102 221 [1]. 

When both the terminal and the UICC are supporting the SWP interface, several operation modes become possible in 
addition to the operation modes already supported by terminal not supporting the SWP interface and the UICC: 

• Only the SWP interface is activated. This may occur while the whole terminal is powered and other interfaces 
(e.g. the TS 102 221 [1] or TS 102 600 [6] interfaces) are idle or not activated, or while the terminal is 
switched OFF (i.e. the whole terminal may not be operative). 

• The SWP interface is activated while a session on another terminal-UICC interface is in progress (e.g. the 
TS 102 221 [1] or TS 102 600 [6] interface). In this case, the different interfaces shall be active concurrently, 
and therefore actions on the SWP interface shall not disturb the terminal-UICC exchange on the other 
interfaces and vice-versa. 
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5.4 Interaction with other interfaces 

Communication between a terminal supporting the SWP interface and a UICC supporting the SWP interface take place 
either over the SWP interface on contact C6 as specified in the present document, or over the interfaces using contacts 
C2, C3, C4, C7 and C8 as defined in TS 102 221 [1] and TS 102 600 [6]. Signalling on a contact assigned to one 
interface shall not affect the state of other contacts assigned to another interface. This also applies to the activation 
sequence of the UICC. The power provided on contacts CI (Vcc) and C5 (Gnd) shall cover the power consumption of 
all active interfaces of the UICC. 

Operation of the SWP interface after activation shall be independent from operation of other interfaces (e.g. the 
TS 102 221 [1] or TS 102 600 [6] interface) that may be implemented on the UICC. 

Any reset signalling (RST signal on contact C2 as specific to the TS 102 221 [1] interface or logical reset on 

TS 102 600 [6] interface) shall only affect the UICC protocol stack related to these interfaces. SWP-related processes 

shall not be affected by another interface reset signal. 

A logical reset signalling on the data link layer (SHDLC RSET) over the SWP interface as well as activation and 
deactivation of SWP interface shall not affect any of the other interfaces. 



6 Physical characteristics 

6.1 Temperature range for card operation 

In the present document, all parameter values for the SWP interface shall apply for the standard temperature range for 
storage and full operation as defined in TS 102 221 [1]. 

6.2 Contacts 

6.2.1 Provision of contacts 

Vcc (contact CI) and Gnd (contact C5) provided in the UICC shall be reused by the terminal to provide power supply. 
S WIO (contact C6) of the UICC shall be used for data exchange between the UICC and the CLF. 

6.2.2 Contact activation and deactivation 

The terminal shall connect, activate and deactivate contacts C2, C3 and C7 of the UICC in accordance with the 
operating procedures specified in TS 102 221 [1] and the contacts C4 and C8 in accordance with the operating 
procedures specified in TS 102 600 [6] when these interfaces are used. The terminal shall activate the contact CI (Vcc) 
according to the TS 102 221 [1]. 

A terminal may decide not to perform the contact and interface activation of SWP if it detected in either this or a 
previous card session that the UICC does not support the SWP. 

6.2.2.1 SWP contact activation 

As long as Vcc (contact CI) is not activated, the terminal shall keep SWIG (C6) in the DEACTIVATED state (SI 
state L). 

The terminal activates Vcc (Contact CI) in order to either activate the SWP interface or the contact Vcc (Contact CI) is 
activated due to the activation of another interface on the UICC. 

The activation of the SWIG (Contact C6) takes place when the terminal sets the SWIG signal from state L to state H. 
This indicates to the UICC to activate its SWP interface. 
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6.2.2.2 SWP contact deactivation 

The terminal shall set SWIO (Contact C6) to the DEACTIVATED state as defined in clause 8.3 (SI state L) prior to 
deactivating the Vcc. 

6.2.2.3 Deactivation of the UICC 

In addition to the deactivation as given in TS 102 221 [1] and TS 102 600 [6] the terminal shall deactivate SWIO 
(contact C6) before deactivating Vcc (Contact CI). 

6.2.3 Interface activation 

After the activation of the SWIO (contact C6) the CLF shall put SWP into SUSPENDED state to indicate that it is 
ready to exchange data via SWP. 

The process following thereafter makes use of the ACT LLC layer as described in clause 9.4. 

The sequence is as follows: 

• The UICC shall indicate that it is ready to exchange data via SWP by resuming SWP and sending the P*^ 
ACT_SYNC frame. The CLF shall put SWP into ACTIVATED state and receive the pt ACT_SYNC frame 
with the bit duration in the default range as described in clause 8.1. 

In case the CLF responds to the SWP resume condition, the UICC shall recognize interface activation of 
SWP. 

In case the CLF does not put SWP into ACTIVATED state upon "SWP resume by the UICC condition", 
the UICC shall stop the SWP resume sequence (see T§2 inhibit ™ table 6.1), The UICC shall not 
respond to further attempts from the CLF to communicate via SWP and shall wait for UICC deactivation 
or shall retrieve information about SWP capability of the terminal via any other UICC interface (see 
clause 6.2.4). 

In case the CLF does not recognize SWP resume by the UICC, the CLF shall assume that the UICC does 
not support SWP interface and the CLF may deactivate SWIO (contact C6) or may deactivate the UICC. 

• When the CLF has received the P^ ACT_SYNC frame from the UICC, the CLF shall take the following 
actions: 

If the CLF has received a correct ACT_S YNC frame and the terminal provides full power mode, the 
CLF shall respond with an ACT_POWER_MODE frame indicating full power mode. 

If the CLF has received a correct ACT_S YNC frame and the terminal provides low power mode, the 
CLF may respond with an ACT_POWER_MODE frame indicating low power mode. 

If the CLF has received a corrupted frame the CLF shall request the UICC to repeat the last ACT_S YNC 
frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal 
power mode. 

• When the UICC has received an ACT_POWER_MODE frame, the UICC shall take the following actions: 

If the UICC has received a correct ACT_POWER_MODE and the FR bit of this frame is 1, then the 
UICC shall repeat the ACT_S YNC frame. If the FR bit is then the UICC shall respond with an 
ACT_READY frame. 

If the UICC has received a corrupted frame, the UICC shall not respond. 

NOTE: The UICC may change its power mode as described in clause 8.4. 

• When the CLF has received an ACT frame in response to an ACT_POWER_MODE frame, the CLF shall take 
the following actions: 

If the CLF has received a correct ACT frame, it shall not send further ACT frames. 
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If the CLF has received a corrupted ACT frame, the CLF shall request the UICC to repeat the last ACT 
frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal 
power mode. 

• When the CLF has not received an ACT frame in response to an ACT_POWER_MODE frame, the CLF shall 
take the following actions: 

In this case, the CLF shall request the UICC to repeat the last ACT frame by sending an 
ACT_POWER_MODE frame with FR bit set to 1 indicating the current terminal power mode. 

• The CLF shall not send more than three ACT_POWER_MODE frames with the FR bit set to 1 . 
The interface activation is called successful when both of the following two conditions are met: 

• the CLF has received a correct ACT_SYNC frame; 

• if the CLF has sent an ACT_POWER_MODE frame that was correctly responded to by the UICC with an 
ACT frame. 

If the interface activation was not successful the CLF shall assume that the UICC does not support S WP interface. In 
this case the CLF may deactivate SWIO (contact C6) or may deactivate the UICC. 

This interface activation sequence shall also be applied when the SWP is activated from the state DEACTIVATED, 
with the following modifications: 

• The UICC shall not send an ACTJNFORMATION field in any of the ACT frames. 

• If the previous successful interface activation indicated full power mode, and when the CLF has received the 
pt ACT_SYNC frame from the UICC, the CLF shall take the following action: 

If the CLF has received a correct ACT_S YNC frame, the CLF may respond with an 
ACT_POWER_MODE frame indicating full power mode. 

If the CLF has received a corrupted frame the CLF shall request the UICC to repeat the last ACT_S YNC 
frame by sending an ACT_POWER_MODE frame with FR bit set to 1 indicating full power mode. 

Figure 6.1 shows the timing conditions for the initial interface activation after Vcc (contact CI) activation, for the case 
when an ACT_POWER_MODE frame is sent. Table 6.1 gives the timing values. 
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Trf 1st cmd(*1 




NOTE 1 : The relationship to RF-field appearance is shown for information only. 

NOTE 2: Timing marl<ed (*) are informative. The compliancy to the startup time of the RF application Tpp ^^^ q^q 

(for ISO/IEC 14443-3 [3]: 5msec from RF-field 1.5A/m to be able to receive REQA, REQB) is achieved by 
the CLF by balancing Tpp ^qq, Tg^ /^qj p^, T^Lpi^u and the SWP bit rate properly. The system is 

designed in a way, that the CLF may keep the timing constraints when relying on the 1®' SYNC_ID 
transmission. In case this fails it is up to the CLF to request resending SYNCJD and go for the next 
REQA, REQB. 
NOTE 3: The value of Tg^ f^^j ppp implemented by the CLF should be greater than Tg^ f^^j ppp + the SWP 

resume time. This is to ensure that an ACT frame from the CLF is not sent when an ACT(response) frame 
from the UICC is sent. 

Figure 6.1 : Initial interface activation on RF-field appearance (example) 
Table 6.1 : Timing parameters for initial interface activation on RF-field appearance 



Symbol 


Parameter 


Minimum 


Maximum 


Unit 


"''S1_HIGH_V 


SWIQ (contact C6) activation time after 
Vcc (contact C1) activation. 


1 000 


- 


MS 


"''S2_ACT_RES_V 


UICC resumes SWP for sending l^t 
ACT SYNC frame. 





700 


MS 


''"S2_ACT_FRP 


UICC responds 2"^ ACT_SYNC frame 

after ACT POWER IVIODE (calculated from 

last bit of EOF to SWP resume). 





2 000 


MS 


TsajNHIBIT 


UICC re-enters SUSPENDED in case the 
CLF did not respond to resume 


- 


100 


ms 
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The interface activation from the SWP DEACTIVATED state is given in figure 6.2 for the case when an 
ACT_POWER_MODE frame is sent. The timing values are given in table 6.2. 



Trf 1st cmd(*) 








G 




E 


u. 


r^'o'f^ 


Ll 




O 


(1 


1 


t/i 




LU 



o °a. 

< &o 



NOTE 1 : The relationship to RF-field appearance is shown for information only. 

NOTE 2: Timing marked (*) are informative. The compliancy to the startup time of the RF application Tpp ^3, q^q 

(for ISO/I EC 14443-3 [3]: 5 ms from RF-field 1 ,5 A/m to be able to receive REOA, REQB) is achieved by 
the CLF by balancing Tg^ ^|q^ q, Tg., ^qj p^, T^Lpn^u q and the SWP bit rate properly. The system is 

designed in a way, that the CLF may keep the timing constraints when relying on the 2"'^ SYNC_ID 
transmission in case the 1^' transmission fails. 

Figure 6.2: Interface activation from the DEACTIVATED state on RF-field appearance (example) 

Table 6.2: Timing parameters for the interface activation 
from the deactivated state on RF-field appearance 



Symbol 


Parameter 


Minimum 


Maximum 


Unit 


TS2_ACT_RES_D 


UICC resumes SWP for sending l^t 
ACT SYNC frame 





500 


MS 



Depending on the power state of the UICC the following conditions for the interfaces shall apply: 

• If the UICC is in "low power mode" the terminal shall not activate the TS 102 221 [1] interface and if the 
UICC supports the USB interface according to TS 102 600 [6], it shall not perform an attachment on the USB 
interface. 

• If the UICC is in "full power mode", the terminal may independently activate any other UICC interfaces. 
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• If the UICC was activated according to TS 102 221 [1], an additional activation of the SWP interface shall be 
considered as selected application on the UICC. 

6.2.4 Behaviour of a UICC in a terminal not supporting SWP 

The UICC shall take care of terminals having C6 contact connected with low impedance to Vcc or electrically isolated 

When the UICC detects that the contact C6 is not connected to Vcc it shall connect the C6 contact with a low 
impedance to Gnd within 2 seconds after detecting that the terminal does not indicate the support of SWP interface. 

NOTE: Implementation has to take care to minimize SWP related power consumption. 

6.2.5 Behaviour of terminal connected to a UICC not supporting SWP 

When the terminal detects that the UICC does not support SWP, it shall keep SWIG in the deactivated state (state L). 

6.2.6 I n active CO ntacts 

The conditions for inactive contacts as defined in TS 102 221 [1] shall apply to contact C6. 



7.1 



Electrical characteristics 
Operating conditions 



The voltage levels for the CLF (Master) and the UICC (Slave) signal SI are illustrated in figure 7.1. 



Vqh max 
1,8 V 

Vqh min 



^OL max 
Gnd 



CLF (Master) 



UICC (Slave) 

tac 
V 



Input voltage 



IH max 



Valid range for S1 high 



V 



IH min 



.V 



IL max 



Valid range for S1 low 



-V 



IL min 



Figure 7.1 : Voltage definitions for thie signal 81 

Vjjj and VjL refers to the receiving device signal level (Slave). Vqjj and Vq^ refers to the sending device signal level 
(Master). All voltages are referenced to Gnd. 

The SWP interface uses a second signal S2 which is the current from the master to the slave and allows data to be sent 
back from the slave to the master. S2 values are defined when SI is state H. The current levels for S2 are defined in 
clause 7.1.4.1, as shown in figure 7.2. 
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S2 (Current) 




H max 



H min 




L max 



L min 



Figure 7.2: Definitions of the current level for S2 on SWIO 

7.1.1 Supply voltage classes 

A UICC supporting the SWP interface shall support the voltage classes B and C, as defined in TS 102 221 [1]. 

7.1 .2 Vcc (CI ) low power mode definition 

When the system operates in low power mode table 7. 1 applies. 

Table 7.1 : Electrical characteristics of Vqq in low power mode 



Symbol 


Conditions 


Minimum 


Maximum 


Unit 


Vcc 


Class C 


1,62 


1,98 


V 


'cc 


Class C 




5 


mA 


NOTE: The current value is averaged over 1 ms. 



The maximum current in the table 7T is defined for the UICC. The terminal may deliver more. The voltage value shall 
be maintained within the specified range despite transient power consumption as defined in table 7.2. 

Table 7.2: Spikes on \qq 



Class 


Maximum charge 
(see note 1 ) 


Maximum duration 


Maximum variation of I^q 
(see note 2) 


C 


6 nA.s 


400 ns 


30 mA 


NOTE 1 : The maximum charge is halt the product of the maximum duration and the maximum variation. 
NOTE 2: The maximum variation is the difference in supply current with respect to the average value. 



7.1.3 Signal SI 



SI is a signal in the voltage domain to transmit data from the CLF to the UICC on SWIO (contact C6). SI shares the 
same electrical contact as S2 as defined in clause 7.1.4. Electrical characteristics of SI are given in tables 7.3 and 7.4. 
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Table 7.3: Electrical characteristics of SWIO for S1 under 
normal operating conditions in voltage class B 



Symbol 


Parameter 


Conditions 


Minimum 


Maximum 


Unit 


VOH 


Output High Voltage (high) 


'Lmin- ' - 'nmax 


1,40 


1 ,98 (see note) 


V 


Vol 


Output Low Voltage (low) 


-20 liA < 1 < 20 liA 


(see note) 


0,3 


V 


V,H 


Input High Voltage (high) 


'lmin- ' - 'Hmax 


1,13 


2,28 (see note) 


V 


V|L 


Input Low Voltage (low) 


'Lmin- ' - 'Hmax 


-0,3 


0,48 


V 


NOTE: To allow for overshoot the voltage on SWIO shall remain between -0,3 V and Vq^ max + ^'■^ ^ during 
dynamic operation. 



Table 7.4: Electrical characteristics of SWIO for S1 under 
normal operating conditions in voltage class C 



Symbol 


Parameter 


Conditions 


Minimum 


Maximum 


Unit 


VoH 


Output High Voltage (high) 


'Lmin- ' - 'hmax 


0,85 xVcc 


V(,(, (see note) 


V 


Vol 


Output Low Voltage (low) 


-20 liA < 1 < 20 liA 


(See note) 


0,15 xVcc 


V 


V,H 


Input High Voltage (high) 


'l min - ' - 'h max 


0,7xVcc 


Vcc+0,3 


V 


V|L 


Input Low Voltage (low) 


'Lmin- ' - 'hmax 


-0,3 


0,25 xVcc 


V 


NOTE: To allow for overshoot the voltage on SWIO shall remain between -0,3 V and V(,(,+ 0,3 V during 
dynamic operation. 



7.1.4 Signal S2 



S2 is a signal in the current domain to transmit data from the UICC to the master. S2 shares the same electrical contact 
as S 1 (contact C6). In this clause the electrical characteristics of S2 are described. 



7.1.4.1 



Operating current for S2 



S2 is considered as in state H when the current drawn on SWIO is between lu ■„ and It, „,^^ and is considered in state L 

ri mm ri mdx 

when the current drawn on SWIO is between I^ ujjn and I^ j^^x- 

Table 7.5: Electrical characteristics of SWIO for S2 under normal operating conditions 



Symbol 


Parameter 


Conditions 


Minimum 


Maximum 


Unit 


'h 


High Current 


V|Hmin^S1<V,Hmax 


600 


1000 


MA 


'l 


Low Current 


V|Hmin^S1<V|Hmax 





20 


MA 
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8 Physical transmission layer 

8.1 S1 Bit coding and sampling time (Self-synchronizing code) 

The bit coding of S 1 is illustrated in figure 8.1. 



V 



S1 



V 




Logical 1 



Logical 



Figure 8.1 : Bit-coding of SI 

The nominal duration of the state H for a logical 1 is 0,75 x T, the nominal duration of the state H for a logical is 
0,25 X T. 

All bits shall be transmitted consecutively. The bit-duration may be different for each transmitted bit. 

Before the start of a transmission of consecutive bits, S WIO shall be in SUSPENDED state (S 1 state H) as defined in 
clause 8.3. 

At the end of the bit-duration T, the master shall always set S 1 to state H. 



Tr 



TH 



-H- 90% 



50% 



T---- 

Signal 
amplitude 



V 10%- 




Figure 8.2: S1 waveform 
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The input capacitance of the UICC (Clqad ) ^'^ ^^^ ^^ contact shall not exceed 10 pF. Table 8.1 gives SI waveform 
timing. 

Table 8.1 : S1 waveform timings 



Symbol 


Parameter 


Conditions 


Minimum 


Nominal 


Maximum 


Unit 


tp 


Fall time 


Cload^IOpF 
T < 5 000 ns 


5 ns 


~ 


0,05 xT 




Cload^IOpF 
T > 5 000 ns 


5 ns 


- 


250 ns 




tR 


Rise time 


Cload^IOpF 
T < 5 000 ns 


5 ns 


~ 


0,05 xT 
(see note 1) 




Cload^IOpF 
T > 5 000 ns 


5 ns 


- 


250 ns 
(see note 1) 




Thi 


Duration of the state H for 
coding a logical 1 of S1 




0,70 xT 


0,75 xT 


0,80 xT 




"•"ho 


Duration of the state H for 
coding a logical of S1 




0,20 xT 


0,25 xT 


0,30 xT 




T 
(see note 2) 


Default Bit duration 




1 


- 


5 


^s 


Extended bit duration 




0,295 


- 


10 


MS 


NOTE 1 : Valid for the leading edge and the trailing edge of each bit. 
NOTE 2: Extended bit durations are indicated as per table 9.3. 



8.2 S2 switching management 



S2 is valid only when SI is in state H. The UICC (Slave) shall only perform switching of S2 when SI is in state L. 
Figure 8.3 illustrates the timing of S2 related to SI. 



V 



VoHmin 

S1 



% T- 



Va T 



A 

k 



'Hrtiin 

S2 

'Lmax 



Logical 



Logical 1 




S2 is undefined 



S2 Valid 



Figure 8.3: S2 timing 
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8.3 SWP interface states management 

SWIO has three different states: 
ACTIVATED: 

In this state a data exchange is on going. 

S 1 provides a continuous sequence of logical and logical 1 . 

SWIO remains in this state until a SUSPEND condition is provided. 

SUSPENDED: 

In this state SI is in state H and S2 is in state L. This state is the initial state of SWIO at activation of the SWP interface. 

SWIO remains in this state until a RESUME or DEACTIVATE condition is provided on the SWIO. 

DEACTIVATED: 

In this state the signal S 1 is in state L and the signal S2 is in state L. 

SWIO remains in this state until an ACTIVATE condition is provided on the SWIO. 

The following transitions between these states are defined as follow: 

RESUME: 

Signal condition to exit from SUSPENDED state to ACTIVATED state. Both the master and the slave may execute a 
RESUME to bring SWIO in ACTIVATED state at any time. 

The master resumes by sending P2 consecutive idle bits. SWIO exits the SUSPENDED state and enters the 
ACTIVATED state after the last of these bits sent by the master. 

The slave resumes by drawing a current (S2 in state H) for more than PSj^^jj^ time, the master shall respond by setting SI 
in state L for a time Tj^q in less than PSjj^^j^ time. After this resume sequence, SWIO exits the SUSPENDED state and 
enters the ACTIVATED state when the master sets S 1 in state H. After this wakeup bit, the slave shall send a SOF not 
later than a maximum of 4 idle bits. 



SUSPENDED 



ACTIVATED 



SUSPEND: 



S1 



RESUME 

P3 ; T-TH-O 



00000000 



Figure 8.4: Resume by the slave timing 




If there is no activity on SWIO, other than idle bits (logical on SI and S2) during PI time, the master may switch 
SWIO to the SUSPENDED state by maintaining S 1 in state H. 

DEACTIVATE: 

If SWIO is in SUSPENDED state, the master may switch the line to the DEACTIVATED state by maintaining SWIO 
in state L for longer than P4 time. 
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ACTIVATE: 

If SWIO is in DEACTIVATED state, the master shall switch the hne to the SUSPENDED state by putting SWIO in 
state H and initiate the interface activation procedure as described in clause 6.2.3. The slave may request activation of 
the interface by using the ACTIVATE INTERFACE command as defined in TS 102 223 [7]. 

Figure 8.5 illustrates an example of SWIO activities. 




S2 



Figure 8.5: Bus activity 



Table 8.2 gives SWIO management timings. 



Table 8.2: SWIO Management Timing 



Symbol 


Parameter 


Minimum 


Maximum 


Unit 


P1 


Suspend sequence 


7 


7 


Bit 


P2 


Slave Resume sequence (By the master) 


8 


8 


Bit 


P3 


Master Resume time (By the slave) 


0,5 


5 


MS 


P4 


Deactivation time 


30 


- 


MS 



8.4 Power mode states/transitions and Power saving mode 

When the terminal activates Vcc (contact CI) the UICC shall enter the initial power state. This initial power state of the 
UICC shall conform to TS 102 221 [1]. 

Thereafter the terminal may activate the interfaces as described in clause 6.2. Upon activation of at least one interface, 
the UICC enters the operational power state. 

NOTE 1 : The initial power state and the operational power state are part of the full power mode. 
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If during SWP interface activation the terminal sends a power mode frame indicating low power mode, the UICC shall 
enter this mode. Switching from low power mode to full power mode shall be done by an upper layer command out of 
the scope of this specification. This transition may interrupt an ongoing contactless transaction due to internal UICC 
processing. 

Switching from full power mode to low power mode requires deactivation of Vcc (contact CI). 

The UICC shall enter the power saving mode when all of the following conditions for activated interfaces are given: 

• clock stop mode according to TS 102 221 [1] if this interface is activated (if UICC is in full power mode); 

• suspend mode according to TS 102 600 [6] if this interface is activated (if UICC is in full power mode); 

• SWP contact deactivated (if UICC is in full power mode or in low power mode). The UICC shall enter the 
power saving mode no later than 10ms after the SWP interface is deactivated. 

When the UICC is in power saving mode it shall not exceed the current defined for clock stop mode in TS 102 221 [1] 
or the limit given for suspend mode in TS 102 600 [6] whatever the interface is activated. 

The UICC shall exit the power saving mode when at least one of the UICC interfaces is resumed from these conditions. 

NOTE 2: In full power mode, all the resources in the terminal (e.g. display, keyboard, etc.) may not be available for 
the UICC applications. 



Data link layer 



9.1 



Overview 



The Data Link layer manages LPDUs (Link Protocol Data Unit) as illustrated in figure 9.1. This layer can be divided 
into two sub-layers: 

• MAC layer is in charge of framing. 

• LLC layer is in charge of error management and flow control. 



Packet 


: 


LLC layer 


:: 


LPDU 


: 


MAC layer 




Frame 



Figure 9.1 : Data link layer overview 



9.2 Medium Access Control (MAC) layer 

9.2.1.1 Bit order 

The bit order of the SWP communication channel is MSB first. 
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9.2.1.2 Structure 

Figure 9.2 illustrates the format of a frame sent from the master to the slave. 

Bit Stuffing 



SOF FLAG 



Pay load 



CRC16 



EOF FLAG 



1111110 






1 


1 


1 


1 


1 


1 


1 



V 



y 



V 



6x1 7x 1 

Figure 9.2: Frame structure sent by master 

The SOF flag has the value 7E' and the EOF flag has the value 7F'. Between frames, idle bits (logical value 0) are sent. 
There is at least one idle bit between frames. 

Figure 9.3 illustrates the format of a frame sent from the slave to the master. 

Bit Stuffing 



SOF FLAG 



Payload 



CRC16 



EOF FLAG 



1 





1 


1 


1 


1 


1 


1 









1 


1 


1 


1 


1 


1 


1 



1 



V 



y 



y 



6x1 



7x1 



Optional Wakeup bit 
(see below) 



Figure 9.3: Frame structure sent by slave 



A wakeup bit (logical value 1) shall be inserted before the first frame from the slave to the master when the slave issue a 
RESUME sequence and may be inserted before each frame from the slave to the master in order to avoid deadlock states 
when the slave starts a transmission just before the bus suspend sequence. 

The payload size is limited to 30 bytes. The CRC field is 16 bits long. 



9.2.1.3 



Bit Stuffing 



In order to detect the SOF and EOF flags, the bit stuffing principle is applied within the SWP frames between the SOF 
and EOF flags. After five (5) consecutive logical one (1) bits, a bit with the logical value is inserted. The frame 
decoding applies the reverse principle. 
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Bit stuffing 

Figure 9.4: Bit stuffing 
9.2.1.4 Error detection 

The detection of errors in a frame is based on the standard CRC-16 CITT. The CRC polynomial is: 

Xl6+xl2+x5+l. 
Its initial value is OxFFFF. 
The CRC is computed on the bits between SOF and EOF both excluded. 



9.3 Supported LLC layers 



Three Logical Link Control (LLC) layers using the previously defined MAC layer are defined in this specification: 

• SHDLC: This is the generic LLC used during most of the contactless transactions. SHDLC is defined in the 
following sub clauses of the present document. Support of this LLC in mandatory in the CLF and the UICC. 

• CLT: This LLC is used for some proprietary protocol handling. CLT mode is defined in the clause 11. Support 
of this LLC is optional in the CLF and optional (application dependant) in the UICC. 

• ACT: This LLC consist of frames used during interface activation. After UICC and CLF have started 
communication using SHDLC or CLT, UICC and CLF shall not respond to any received ACT frame. Support 
of this LLC is mandatory in the CLF and the UICC. 

Table 9.1 : LLC Control field coding 



Frame Types 


Bit Field 


8 


7 


6 1 5 1 4 1 3 1 2 1 1 


RFU 








All settings 


ACT 





1 


1 


ACT type 


CLT 





1 





CLT CMD 


SHDLC 


1 


All settings 



The control field is the first byte of the S WP frame payload. Definition for the different LLC layers can be found in 
table 9.1. 

The LPDUs payload shall be structured according to figure 9.5. 
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LLC CONTROL FIELD 



^r 



ACT TYPE 



to 3 BYTES 



ACT PAYLOAD 



y^ 



ACT LPDU 



LLC CONTROL FIELD 



MAX 29 BYTES 



^r 



CLT CMD 



y^ 



CLT PAYLOAD 



CLT LPDU 





LLC CONTROL FIELD 






MAX 29 BYTES 








~^ 




^■N 


/" 


r 




X 


1 


SHDLC 

CONTROL 

FIELD 






HDLC PACKET 






L 


/ 


V 




J 










SHDLC LPDU 




* 













Figure 9.5: LPDU structure of the 3 defined LLC layers 



9.4 ACT LLC definition 

The ACT LPDU shall be structured according to figure 9.6. 
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ACT LLC CONTROL FIELD 



-►-* 



ACT PAYLOAD 



■^T" 



ACT_ 
CTRL 



ACT_DATA 
(0 to 2 Byte) 



ACTJN FORMATION 
(0 to 1 Byte) 



y^ 



ACT TYPE 



ACT LPDU 



Figure 9.6: ACT LPDU structure 

Coding of ACT TYPE: 

• Meaning of FR in a frame when received by the UICC: 

FR = 1 : The UICC shall repeat the last sent ACT frame. 
FR = 0: The UICC shall not repeat the last ACT frame. 

• Meaning of FR in a frame when received by the CLF: 

The CLF shall ignore the FR bit. 
A frame sent from the UICC to the CLF shall have the FR bit set to 0. 

• Meaning of INF in a frame when received by the CLF: 

INF = 1 : Last byte of ACT payload contains the ACTJNFORMATION field. 
INF = 0: ACTJNFORMATION field not available. 

• Meaning of INF in a frame when received by the UICC: 

The UICC shall ignore the INF bit. 
A frame sent from the CLF to the UICC shall have the INF bit set to 0. 
The meaning of ACT_CTRL and ACT_DATA is given in table 9.2. 

Table 9.2: Meaning of ACT_CTRL and ACT_DATA 



ACT CTRL 


Meaning 


ACT DATA FIELD 


000 


ACT_READY 
Sent from UICC to CLF 


Byte 


010 


ACT_POWER_MODE 

Sent from CLF to UICC to indicate the power 

mode for the UICC. 


1 Byte 

'00': Low power mode 

'01': Full power mode 

(see Note) 


001 


ACT SYNC: VERIFY SYNC ID 

Sent from UICC to CLF to control the SYNCJD 

verification process. 


2 Byte SYNC_ID 


All other values 
(see note) 






NOTE: All other values are reserved for future use. These values shall not be set by the transmitting entity and 
shall be ignored by the receiving entity. 
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ACTJNFORMATION: By sending this field, the UICC indicates extended capabilities as defined in table 9.3. 
Table 9.3: Extended capability indication in ACTJNFORMATION field 



Bit field 


Value 


Meaning 


8 





Reserved for future use 


7 





Reserved for future use 


6 





Reserved for future use 


5 





Reserved for future use 


4 





Reserved for future use 


3 


1 




SWP bit durations down to 295 ns supported 
(the value of bit field 2 shall be 1) 

SWP bit durations down to 295 ns not supported 


2 


1 




SWP bit durations down to 590 ns supported 
SWP bit durations down to 590 ns not supported 


1 


1 




SWP bit durations up 10000 ns supported 
SWP bit rates down to 10000 ns not supported 



9.4.1 SYNC_ID verification process 



The purpose of the S YNC_ID Verification is to protect RF communication parameters in the CLF that have been 
provided by the UICC. The SYNC_ID Verification process consists of the following steps: 

• The UICC presents the SYNC_ID to the CLF. The presented SYNC_ID is named verification data. 

• The CLF compares verification data with reference data. These reference data are stored in the CLF during 
system configuration (or reconfiguration). 

If both values are equal, UICC and CLF are called synchronized. 

For the SYNC_ID Verification, the following conditions shall apply: 

• The CLF and the UICC shall support SYNCJD verification. 

• The SYNC_ID Verification shall always be executed when the SWP interface is activated (see clause 6.2.3). 

The CLF shall perform the SYNC_ID verification process based on ACT frames received from the UICC as outlined 
below: 

• In case the ACT_CTRL field "VERIFY SYNC_ID" is received, the CLF shall use the ACT_DATA field as 

verification data. 

If the CLF evaluates that verification data and reference data are not equal (UICC and CLF are not synchronized), the 
CLF shall inhibit all contactless card emulation services for the UICC up to the next system reconfiguration. 

A system reconfiguration shall - with respect to the SYNC_ID Verification process - execute the following steps: 

• The UICC shall generate a new SYNC_ID. 

• The UICC sends the RF communication parameters and the SYNC_ID to the CLF. 
For this process the following rules shall apply: 

• UICC and CLF shall use the HCI framework to transmit this reconfiguration information. 

• The CLF shall store RF communication parameters and the SYNC_ID transmitted over the physical SWP 
interconnection between UICC and CLF. 

• Applications on the UICC using the SWP interface for contactless communication between the terminal and a 
reader device shall send RF communication parameters and the SYNC_ID over the physical SWP interface. 
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The generation of subsequent SYNC_ID values shall incorporate a random element. 



10 SHDLC LLC definition 
10.1 SHDLC overview 

The SWP SHDLC layer as defined in the present document is a simplified version of ISO's High-level Data Link 
Control (HDLC ISO/IEC 13239 [5]) specification. It is responsible for the error-free transmission of data between 
network nodes. 

The SHDLC layer shall ensure that data passed up to the next layer has been received exactly as transmitted (i.e. error 
free, without loss and in the correct order). Also, the SHDLC layer manages the flow control, which ensures that data is 
transmitted only as fast as the receiver may receive it. 

SHDLC ensures a minimum of overhead in order to manage flow control, error detection and recovery. If data is 
flowing in both directions (full duplex), the data frames themselves carry all the information required to ensure data 
integrity. 

The concept of a sliding window is used to send multiple frames before receiving confirmation that the first frame has 
been received correctly. This means that data may continue to flow in situations where there may be long "turnaround" 
time lags without stopping to wait for an acknowledgement. 



10.2 Endpoints 



SHDLC communication occurs between two endpoints. Those endpoints are identified as the CLF and the UICC. Either 
of the endpoints may initiate the link establishment. There is no priority of traffic. 



CLF UICC 

SHDLC 





Figure 10.1: Endpoints 



10.3 SHDLC frame types 



SHDLC uses several types in order to transfer data and to manage or supervise the communication channel between the 
two endpoints (ends of the communication channel): 

• Frames (Information frames): Carry upper-layer information and some control information. I-frame 
functions include sequencing, flow control, and error detection and recovery. I-frames carry send and receive 
sequence numbers. 

• S-Frames (Supervisory Frames): Carry control information. S-frame functions include requesting and 
suspending transmissions, reporting on status, and acknowledging the receipt of I-frames. S-frames carry only 
receive sequence numbers. 

• U-Frames (Unnumbered Frames): Carry control information. U-frame functions include link setup and 
disconnection, as well as error reporting. U-frames carry no sequence numbers. 
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10.4 Control Field 

The SHDLC control field has the structure described in table 10. 1, including the first bits of the payload. 

Table 10.1 : SHDLC Control field coding 



Frame Types 


Bit Field 


8 


7 


6 1 5 1 4 


3 1 2 1 1 


1 


1 





N(S) 


N(R) 


S 


1 


1 





TYPE 


N(R) 


U 


1 


1 


1 


M 



where: 

• N(S): Number of the information frame 

• N(R): Number of next information frame to receive 

• TYPE: Type of S -Frame 

• M: Modifier bits for U-Frame 

The size of the sliding window is four frames by default. Frames types may be interleaved. For example, a U-Frame 
may be inserted between I-Frames. 



10.4.1 I-Frames coding 



The functions of the information command and response is to transfer sequentially numbered frames, each containing 
an information field, across the data link. 



10.4.2 S-Frames coding 



Supervisory(S) commands and responses are used to perform numbered supervisory functions such as acknowledgment, 
temporary suspension of information transfer, or error recovery. Frames with the S format control field do not contain 
an information field. 

Supervisory Format commands and responses are as follows: 

• RR: Receive Ready is used by an endpoint to indicate that it is ready to receive an information frame and/or 
acknowledge previously received frames. 

• RNR: Receive Not Ready is used to indicate that an endpoint is not ready to receive any information frames or 
acknowledgments . 

• REJ: Reject is used to request the retransmission of frames. 

• SREJ: Selective Reject is used by an endpoint to request retransmission of specific frames. An SREJ shall be 
transmitted for each erroneous frame; each frame is treated as a separate error. Only one SREJ shall remain 
outstanding on the link at any one time. 

The type coding is given by the table 10.2. 

Table 10.2: Type coding of the S-frames 



Frames 


Type 


Status 


RR 


00 


Mandatory 


REJ 


01 


Mandatory 


RNR 


10 


Mandatory 


SREJ 


11 


Optional 



Optional type of frame shall not be used before capability negotiation is defined during initialization. 
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10.4.3 U-Frames coding 



The unnumbered format commands and responses are used to extend the number of data link control functions. The 
unnumbered format frames (see clause 10.4) have 5 modifier bits which allow for up to 32 additional commands and 
responses. Only a subset of the HDLC commands and responses are used for SHDLC: 

• RSET: Reset of the data link layer is used to reset the receive state variable in the addressed endpoint. 

• UA: Unnumbered Acknowledgment is used to acknowledge the receipt and acceptance of a RSET command. 

Table 10.3: Modifier coding of the U-frames 



Frames 


Modifier 


Status 


RSET 


11001 


Mandatory 


UA 


00110 


Mandatory 



1 0.5 Changing sliding window size and endpoint capabilities 

The sliding window size is a physical property of the link. It shall not change during device life but may be lower than 
the default value due to limited resources. In consequence, an endpoint may want to ask the other endpoint to lower the 
sliding window size. 

The RSET frame may carry a configuration field in order to change the sliding window size (down to 2). If the default 
size (in case of an RSET command without configuration field) or the size provided is too large at a RSET frame 
reception, the receiver shall not acknowledge it. Instead, the receiver shall send a RSET frame with an appropriate 
sliding window size (which is lower than the window size offered by the other endpoint). 

An endpoint shall obey to window size reconfiguration if the requested window size is lower than its default 
configuration. It acknowledges the new size with a UA frame. 

SREJ support is negotiated in the same way. The RSET frame may carry a configuration field in order to indicate the 
capability of the endpoint to support this frame. 

10.5.1 RSET frame payload 

The RSET frame has 2 optional bytes in order to provide the endpoint window size and capabilities. The number 
provided for the endpoint size shall be between 2 to 4 inclusive. In case this RSET frame is sent in response to a 
received RSET frame, the endpoint size value shall be lower than the previously provided value. The second optional 
byte may be sent after the window size by the endpoint in order to indicate support of optional endpoint capabilities. If 
it is absent, the default values apply. 



RSET 



Window 
size 



Endpoint 
capabilities 



1111 1001 


nnnn nnnn 


ba...b, 


8 bits 


8 bits 


8 bits 









2 < nnnn nnnn <4 



Figure 10.2: RSET frame payload 
Table 10.4: Bit coding of optional endpoint capabilities 



Bit 


Default 
value 


Description 


1 





Support of Selective Reject S-frame (SREJ) 

0: Not supported (default) 

1 : Supported 


2 to 8 


000000 


RFU 
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1 0.5.2 UA frame payload 

The UA frame carries no payload. 

10.6 SHDLC context 

The SHDLC context is defined by constant values such as the timeouts and the sliding window size as well as a number 
of variables as defined below. 

10.6.1 Constants 

• w: Sliding window size, w = 4 by default 

This value is not actually constant because it may be reduced at link establishment. However, up to the next 
reset of the SHDLC session, it never changes. 

• Tl: Acknowledge timeout. ,T1 = 5 ms 

In context of streaming, the frames shall be acknowledged within Tl to avoid that the traffic stops. The Tl 
value is bound to the w value . The current value is computed for w = 4. If the value is reduced to w" then Tl 
is changed to Tl" = Tl xw" / w. 

• T2: Guarding/transmit timeout. T2> T1.T2 = 10 ms 

If the frames are not acknowledged after a time period, a endpoint shall retransmit these frames. This value 
defines the minimal time to wait. T2 is unaffected by modifications of w. 

• T3: Connection timeout. T3 = 5 ms 

Used at link establishment, retry to setup link if the targeted end point did to not answer with an UA frame to a 
RSET frame. T3 is unaffected by modifications of w. 

10.6.2 Variables 

These three variables are modulo 8 and hold sequence numbers. 

• N(S): Sequence number for emission. Used in I Frames. Incremented after emission of the frame. 

• N(R): Next sequence number for reception. Used in I and S type frames. 

During full duplex data transmission or by emission of a S type frame, all received frames with a sequence 
number lower than N(R) are acknowledged. 

• DN(R): Lowest unacknowledged sequence number. 
Acknowledgements are outstanding for frames between DN(R) and N(S). 

To know if a frame is in the window, sequence numbers are compared using modulo 8. 
The definition used for X <= Y <Z modulo 8 is as follows: 

• If X <= Z then the equation to calculate is: X <= Y <Z 

• Otherwise the equation to calculate is: Y >= X or Y < Z 

10.6.3 Initial Reset State 

The following initial states shall apply in every endpoint after successful link establishment: 

• N(S) = N(R) = DN(R) = 0. 
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1 0.7 SHDLC sequence of frames 
10.7.1 Nomenclature 




Frame Boundaries 




Frame with 
Information 



Frame witliout 
Information 



Transmission 
error 



Information frame: 

Receive Ready: 

Reject: 

Reset (no payload): 



Figure 10.3: Frames representation 



I N(S), N(R) 



RR N(R) 



REJ N(R) 



RSET 



Receive and Not 
Ready: 

Selective Reject: 
Reset (with payload): 



RNR N(R) 



SREJ N(R) 



RSET 



WS4 



Figure 10.4: Frames type description 

1 0.7.2 Link establishment with default sliding window size 

An endpoint establishing a communication channel shall initiate the link by sending a RSET frame. If the target is 
ready, it shall answer with an UA frame. The link is established after receiving this acknowledgment. Before link 
establishment, all frames except RSET from other endpoint shall be discarded. The connection timeout is required in 
order to detect failure and restart the operation. In this example, both endpoints work with the default window size and 
the UICC does not send a RSET frame because it received a RSET frame first and agreed on the default window size. 



CLF: 



UICC: 



_Connection_ 
timeout 



|RSET| 



_Unlimited_ 
time 



10,0 



ft 



Figure 10.5: Link establishment restart after UA loss 
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Simultaneous resets are handled gracefully. After both endpoints send UA frames, link is established using the default 
window size. 



iRSET, I UA 1 1 1 I- ■. J I 10,0 

CLF: H H-. ""ZT *\— 



|RSET| I UA| 



|RSET| I UA I 

UICC: 



|noi=i| I UM I 

n n 

Figure 10.6: Link establishment with crossover RSET frames 

1 0.7.3 Link establishment witin custom sliding window size 

If the UICC has a smaller window size than the CLF, it ignores the received RSET frame. The CLF sees the customized 
RSET frame, changes its window configuration to 2 and sends an UA frame to establish the link. 



9 1 UA I , ,„||„;,„H I 10.0 

I 1^ "™ 



I I 

■ RSET. 
lwS2l 



iRSET, 

UICC: 

' *S2 1 Ignore the received RSET. 

Request a smaller sliding 
window size. 



Figure 10.7: Link establishment with sliding window size of 2 

In case of RSET frames crossover, the mechanism still works. 

Change to a lower sliding 
I window size. 

RSET, lUAj M„li,.i,.H I 10,0 I 



CLF: I 1 ^ 'J"'™''^^ 

K^ I r time 



B l UM I 
..„, I I 

|RSET| 
I WS2 I 



iRSET, 

UICC 

IWS2 



Ignore the received RSET. 



Figure 10.8: Link establishment with sliding window 
size of 2 and RSET frames crossover 

In case of frame loss, the link establishment restarts and link configuration is finally completed. 

UA, 



CLF: 


RSET 

M 

WS4 

RSET 


Connection 
timeout 


RSET 

► 

WS4 


RSET 


UICC: 


\£ 






WS2 



n 



Figure 10.9: The RSET frame from the UICC is lost 

.RSET, lUA, rnnnprtinn l"®^^l 1-!^ 

"''■■ Ur- W '=r — tl H 

9 .RSET. 

..„ lwS2l 



UICC: 

I WS2 I I WS2 

Figure 10.10: The UAfrom the CLF is lost and the connection timeout 
allows restarting the link configuration 
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10.7.4 Dataflow 

Once the link is established, both endpoints may exchange data. 

The CLF sends a stream of data. The UICC has no data to send. So, the piggyback mechanism is not used (Frames are 
acknowledged using information frames going in the opposite way). The UICC shall acknowledge frame reception 
regularly in order to avoid traffic stop. An acknowledge timeout is used in order to send RR frames to the CLF. The 
timeout starts at the first received packet after the previous acknowledgement (other RR frame or piggybacking). If the 
UICC sends information frames (not shows here), the acknowledge timeout shall be stopped as piggybacking will 
acknowledge received frames. 



10,0 11,0 12,0 13,0 14,0 15,0 16,0 17,0 10,0 11,0 





CLF: 

,RR3, ,RR6, ,RR1, 



I wr^r^. ^ acknowledge 

'-'"^'^- "* timeout ~ 



1— - — ^ acknowledge ^ ^ acknowledge ^ 

"1 "* timeout ^1 "* timeout ^1 



Figure 10.11 : One way data flow with RR frames acl<nowledgement 

The acknowledge timeout shall not be too long to avoid throughput degradation. Otherwise, the sending endpoint will 
be waiting for the destination to become ready. This diagram shows what happens with a sliding window size of 4 and a 
timeout value that is too large. 

Traffic is suspended — 
I 10,0 I I 13,0 I I 14,0 I 15,0 I 16,0 , 



CLF: 



I 11/^/^. ^^ acknowledge 

'~>''^'^- -^ timeout ~ 



RR4 



Figure 10.12: One way data flow with too long a time for acknowledgement 

In this example, I-Frames flow in both ways. Piggybacking is used to acknowledge received frames during I-Frames 
crossover. Because of last packets crossover, both endpoints use acknowledge timeout to detect when to send a RR 
frame after traffic ends. 



CLF: 



10,0 I 11,0 I 12,0 I 13,0 I 14,1 I |RR3| 

I ^ Acknowledge 

timeout 



iRR3| 



10,2 I 11,3 I 12,4 I |RR5 



I ||p.<^ I I I I Acknowledge 

'-^'*-'*-'- ^ T timeout 



|nnj| 



Figure 10.13: Piggybacking and timed acknowledgement 

10.7.5 Reject (go N back) 

When a frame gets lost in the stream, the destination (here the UICC) will see a gap in the received frame numbers. If 
SREJ is not supported or if several frames got lost, the destination shall send a REJ frame as soon as possible in order to 
restart the stream at the first missing frame. 

I 1 Retransmissions 

I 10,0 I 11,0 I 12,0 I I3|,0/ I 14,1 I I 13,3 i 14,4 , 



CLF: 



^ 



I 10,2 I 11,3 I 12,3 
UICC: ■ 



13,3 I |RR5| 

_^_^_| ^ acknowledge 

timeout 



iRR5| 



UICC saw frame 4 before 
frame 3. 



Figure 10.14: Piggybacking with reject frame after mismatching sequence number 
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1 0.7.6 Last Frame loss 



Each frame shall have a guarding/transmit timeout in order to retransmit frames if the destination does not notice a loss. 
When the last frame is lost, the destination endpoint will not be able to detect it. A RR frame shall be sent to 
acknowledge the last frame but a lost frame will never be requested for retransmission by the destination endpoint by 
using a reject mechanism. 



Retransmission 



I l°.° I 11.0 I 12.0 I 13.0 I l^.y L Transmi t J '^^^ 

y \ timeout n 



UICC: 



10,2 I 11,3 I 12,4 I |RR5| 

_^ acknowledge 

timeout 



iRR5| 



Figure 10.15: Last frame loss in piggybaclting situation 

Figure 10.16 shows the same behaviour when the destination endpoint do not send any traffic (i.e. no piggybacking). 

I Retransmission 



10,0 , 11,0 , 12,0 , 13,0 I I^L Transmit I '^.3 



CLF: I \ \ \ 1 / I / I" timeout "I 1 

B|RR4| |RR5| 
^ acknowledge ^ ^ acknowledge ^ 
"^ timeout *1 "* timeout ^ 

Figure 10.16: Last frame loss in one way data flow 

1 0.7.7 Receive and not ready 

Receive-not-ready (RNR) acknowledges an I-frame, as with RR, but also asks the peer endpoint to suspend 
transmission of I-frames. 

Stop sending frame — i i — Resume traffic 

10,0 I 11,0 I 12,0 I 13,0 I 14,0 I 15,0 i i 16,0 i 17,0 , 



CLF: 



UICC: 



_acknowlGclge_ 
timeout 



| RR3 . |RNR4, RR6, 



Figure 10.17: Stop and resume traffic at UICC request 

10.7.8 Selective reject 

Selective reject (SREJ) is used to request retransmission of just a single frame. 

I 10,0 I 11,0 I 12,0 I I3i,0/ I 14,1 I 15,2 I I 13,3 
CLF: 



UICC: 



10,2 I 11,3 I 12,3 1^"/^ 13,3 I , ,, |RR6| 

' ' ' — ^ — ' ^ acknowledge 



timeout 



irtriDi 



UICC saw frame 4 
before frame 3. 



Figure 10.18: One frame loss in stream 
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10.8 Implementation model 

All calculations on sequence numbers in this clause are done modulo 8. 



10.8.1 Information Frame emission 




Send In(s), 



(S).N(R) 



N(S) = N(S) + 1 



Set T2 for this frame 



Deactivate T1 




Figure 10.19: Information frame emission. 
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10.8.2 Information Frame reception 




SetTI 



Process frame I 



N(R) = N(R) + 1 




YES- 



YES- 



YES- 




-YES- 



Discard 



Send REJn 



(R) 



Deactivate all T2 for 
frames DN{R) to Y-1 



DN(R)=Y 



Figure 10.20: Information frame reception 



£75/ 



40 



ETSI TS 102 613 V7.0.0 (2007-11) 



1 0.8.3 Reception Ready Frame reception 




Deactivate all T2 for 
frames DN(R) to Y-1 



DN(R) = Y 



Figure 10.21 : RR frame reception 



1 0.8.4 Reject Frame reception 





Deactivate all T2 for 
frames DN(R) to Y-1 



DN(R) = N(S) = Y 



Retransmit frames 
starting from N(S) 



Figure 10.22: REJ frame reception 
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1 0.8.5 Selective Reject Frame reception 




Receive a frame SREJy 



Retransmit frame Y 





-YES- 



Deactivate aii T2 for 
frames DN{R) to Y-1 



DN(R)=Y 



Figure 10.23: SREJ frame reception 



10.8.6 Acl^nowledge timeout 




Timeout of T1 



Transmit RR N(R) 



Figure 10.24: Acltnowledge timeout 
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10.8.7 Guarding/transmit timeout 



Timeout of T2 for frame X 



Resend I > 



Set T2 for this frame 




Figure 10.25: Guarding/transmit timeout 



11 



CLT LLC definition 



11.1 System Assumptions 



The following system assumptions are made as the basis for the CL-Tunnelling protocol specification: 

• System partitioning: 

For ISO/IEC 14443-2 [2] and ISO/IEC 14443-3 [3] Type A proprietary protocols, initialization 
(anticollision and selection) of RF protocols is performed by the CLF without UICC involvement. The 
CLE possesses all information necessary. 

For ISO/IEC 18092 [8] 212 /424 kbps passive mode based proprietary protocols as used in existing 
infrastructure, the UICC performs anticollision. 

CLT mode is not required in order to support ISO/IEC 18092 [8] NFCIP-1 mode for P2P 
communication. 

The necessary protocol translation (from RF level to CLT and vice versa) is performed by the CLF. 

• Supported NFC operating modes: 

"NFC Card Emulation", where proprietary RF protocols are processed by the UICC. 
Other NFC use cases are currently out of scope. 

• Supported RF protocols 

ISO/IEC 14443-2 [2] and ISO/[EC 14443-3 [3] Type A based proprietary RF protocols within legacy 
widespread infrastructures. 

ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode based proprietary RF protocols within legacy 
widespread infrastructures. 
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In the current document, alternative RF protocols are not specified in detail, but are not excluded fi-om 
being operated via CLT, as there are (e.g.) ISO/IEC 14443 [2,3] Type B based proprietary schemes, as 
long as the maximum RF fi-ame length (including EDC) of the supported RF protocol does not exceed 
the transport capability of a single CLT frame and the CLF supports the proper RF protocol initialization. 

1 1 .2 Overview 

The CLT protocol is used to exchange data based on SWP physical layer between the CLF and the UICC. The CLF acts 
as a bridge, which composes/removes the type specific RF-frame encapsulation, but keeps the type-specific error 
detection code, which is managed by the UICC. 

A minimum set of administrative commands is implemented as well. 

A CLT session is defined as the sequence of data exchange based on CLT starting from the first CLT frame issued by 
the CLF until an SHDLC frame is issued by the CLF or the UICC, or a reset condition, whatever occurs first. 

In a CLT session, frames are typically exchanged in an half-duplex manner. 

1 1 .3 CLT Frame Format 

According to table 10.1, one of the coding possibilities for the LLC header is used as CLT frame indicator. The coding 
coexists with the coding of SHDLC and ACT LLC. 

Based on this frame header, the following basic CLT LPDU format is defined: 



Byte 1 (CLT_HEADER) 


Byte 2-N (default 30) 


1 CLT_CMD[4:0] 


CLT_PAYLOAD 



The resulting frame is: 



SOF 





1 





CLT_CMD 


CLT_PAYLOAD 


CRC16 


EOF 



The CLT_HEADER is one byte in length and includes the frame type indication 01 in bits 7 and 6 and the CLT_CMD 
field. 

The CLT_PAYLOAD may have the length bytes and shall not exceed the value stated in this specification. It may 
contain data transferred from or to RF side of the CLF, furthermore referenced as "DATA_FIELD". 

The CLT_CMD shall indicate the type of data in the CLT_PAYLOAD and may include additional administrative 
commands exchanged between the CLF and the UICC, furthermore referenced as "ADMIN_FIELD". The interpretation 
of the data in the ADMIN_FIELD is linked to the entity which has submitted the CLT frame (either the UICC or the 
CLF). 
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Bytel 

b8 (MSB) b1 b8 

CLT general LPDU format: 



Byte 2 



ByteN 



b1 



b8 



(LSB) b1 






1 





CLT_CMD 


CLT_PAYLOAD (byte aligned, to N-1 bytes) 



With CLT_PAYLOAD "IS014443 Type A" structured 






1 








ADMIN 


DATA_FIELD (X bytes + Y bits in last byte, starting from LSB) 


1 to 7 bits "don't care" 





With CLT_PAYLOAD "byte aiigned" structured 






1 





1 


ADMIN 


DATA_FIELD (M bytes) 



Figure 11.1 : Typical examples for CLT frames 



11.4 CLT Command Set 

Table 11.1 gives the coding of the CLT_CMD field. 



Table 1 1 .1 : Contents of CLT CMD 



Bit 


Value 


Meaning 


4 




1 


Structure of DATA_FIELD in CLT_PAYLOAD 

Data structure retrieved from ISO/I EC 14443 Type A (see clause 1 1 .5.1) 

Data structure is byte aligned 


3:0 




ADMIN FIELD (see note) 


0000 
1000 

1001 

Other Values 


Interpretation of ADI\/IIN_FIELD sent by the CLF to the UICC: 

Payload contains data to be transmitted 

CL_PROTO_INF(A): The CLF was selected in ISO/IEC 14443-2 [2] and ISO/IEC 14443-3 [3] 

Type A technology (see clause 11.5.3.1) 

CL_PROTO_INF(F): The CLF forwards anticollision data according to ISO/IEC 18092 [8] 

21 2 kbps/424 kbps passive mode (see clause 1 1 .5.3.2) 

Reserved for future use 


0000 
0001 

0010 

Other Values 


Interpretation of ADMIN_FIELD sent by the UICC to the CLF: 

Payload contains data to be transmitted 

CL GOTO INIT: Requests transition of the CLF to initial state of anticollision and selection 

sequence (ISO/IEC 14443-3 [3]) 

CL GOTO HALT: Requests transition of the CLF to 'HALT state of anticollision and selection 

sequence (ISO/IEC 14443-3 [3]) 

Reserved for future use 


NOTE: Valid for CLT frames with CLT CIVID bits 5:4 set to 00 or 01 . 
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1 1 .5 CLT Data Field 

11 .5.1 Type A structured DATA_FIELD 

For CLT frames with ISO/IEC 14443 Type A structured DATA_FIELD, the bit count shall be retrieved implicitly from 
the byte length of the CLT_PAYLOAD, where the interpretation rule depends on the direction the frame is transferred. 

For CLT frames sent from the CLF to the UICC the following table shall apply. 

Table 11.2: Bit length calculation of Type A structured frame (direction CLF to UICC) 



Size [bytes] of 
CLT PAYLOAD 


Number of RF bits 
interpreted by the UICC 


Remarl< 





Treat as error 




1 


7 (starting from LSB) 




2 


9 


1 RF byte + 1 parity bit 


3 


18 


2 RF bytes + 2 parity bits 


...4to8... 


(continue similar way) 




9 


72 


8 RF bytes + 8 parity bits 


10 


Treated as error 




11 


81 


9 RF bytes + 9 parity bits 


...12to17... 


(continue similar way) 




18 


144 


16 RF bytes + 16 parity bits 


19 


Treated as error 




20 


153 


17 RF bytes + 17 parity bits 


...21 to 26... 


(continue similar way) 




27 


216 


24 RF bytes + 24 parity bits 


28 


Treated as error 




29 


225 


25 RF bytes + 25 parity bits 



For CLT frames sent from the UICC to the CLF the following table shall apply. 

Table 11.3: Bit length calculation of Type A structured frame (direction UICC to CLF) 



Size [bytes] of 
CLT PAYLOAD 


Number of RF bits 
sent to PCD by the CLF 


Remark 








Interpretation rule see clause 1 1 .5.2 


1 


4 (starting from LSB) 




2 


9 


1 RF byte + 1 parity bit 


3 


18 


2 RF bytes + 2 parity bits 


...4 to 28... 


(continue similar way) 




29 


225 


25 RF bytes + 25 parity bits 
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Below, the CLT frame layout transporting 4 RF bytes + 4 parity bits is shown as an example. 



Reception of IS014443 Type A frame via RF (w/o MAC layer): 

I Byte1 1 I Byte2 



Byte3 



Byte4 



LSB 



MSB LSB 



MSB LSB 



MSB LSB 



RF-Byte 1 


P 

1 


RF-Byte 2 


P 
2 


RF-Byte 3 


P 
3 


RF-Byte 4 


P 
4 



CLT LPDU via SWP in "IS014443 Type A" structured: 

I Byte1 1 Byte2 1 Byte3 



b8(MSB) 



b1 (LSB) b8 



Byte4 



Note: Pn ...Parity Bit for RF-Byte n 



Bytes 



Bytee 



RF-Byte 1 



RF-Byte 2 



RF-Byte 3 



RF-Byte 4 






1 








ADMIN 


1 1 1 1 1 1 1 
1 1 1 1 1 1 1 


1 1 1 1 1 1 
1 1 1 1 1 1 


P 
1 


1 1 1 1 1 
1 1 1 1 1 


P 
2 




1 1 1 1 
1 1 1 1 
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Figure 1 1.2: Examples for a "Type A structured" CLT frame 

1 1 .5.2 Handling of DATA_FIELD by the CLF 

Due to the nature of RF protocols, the information exchange on RF side is half-duplex, where the PICC sends a 
command and the PICC sends normally a response, but also may not respond to erroneous frames (as per 
ISO/lEC 14443-3 [3]) or to certain commands when operating in proprietary RF schemes, but shall then be ready to 
receive further PICC commands. 

In an architecture consisting of both a UICC and a CLF that operate in CLT, the response or the condition not to 
respond is evaluated by the UICC. This condition is reported to the CLF by means of an empty DATA_FIELD. The 
resulting flow is as follows: 

• After the CLF has received a frame via RF, a CLT frame with DATA_FIELD is composed and sent to the 
UICC. Afterwards, the CLF continues listening to the SWP interface only but does not respond to RF activity, 
unless the RF field disappeared. 

• After the reception of a CLT frame from the UICC, the CLF shall transmit the respective data via RF if the 
DATA_FIELD was not empty, if the D ATA_FIELD was empty no data shall be transmitted via RF. In both 
cases, the CLF then shall enter immediately a state in which it is able to receive new commands from the RF 
interface as well as the SWP interface. 

1 1 .5.3 Handling of ADMIN_FIELD 
11.5.3.1 CL_PROTOJNF(A) 

With this ADMIN command, the CLF shall informs the UICC about the presence of a proprietary RF protocol 
according to ISO/IEC 14443-3 [3] Type A processed in CLT mode. 

CL_PROTO_INF shall be sent by the CLF to the UICC after every successful RF protocol initialization requiring CLT 
mode processing. 

Following actions shall be taken by the CLF for this ADMIN command: 

• After anticollision and selection sequence (ISO/IEC 14443-3 [3] Type A: Received SAK), the next RF frame 
shall be received and its EDC verified. This frame is expected to be formatted according to the 

ISO/IEC 14443-3 [3] and ISO/IEC 14443-4 [4] response and may be the entry sequence of 
ISO/IEC 14443-3 [3] Type A based proprietary RF protocols. 

• In case of an EDC error, no CLT frame shall be sent to the UICC and the CLF handles the error according to 
ISO/IEC 14443-3 [3] and ISO/IEC 14443-4 [4]. 
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NOTE 1: For ISO/IEC 14443 Release 2001-2006, there is a misalignment between ISO/IEC 14443-3 [3] and 
ISO/lEC 14443-4 [4] for error handling at this state (ISO/lEC 14443-3 [3]: Return to IDLE/HALT, 
ISO/IEC 14443-4 [4]: Remain listening). With ISO/IEC 14443 Revision 2007, the ISO/IEC 14443-3 [3] 
condition also applies for ISO/IEC 14443-4 [4]. 

• If the RF frame was correctly received, the first byte shall be checked by the CLE. 

• If the first byte is equal to 'EO' (command RATS, ISO/IEC 14443-4 [4]), then the CLE shall continue 
ISO/IEC 14443-4 [4] processing using a higher level protocol, no CLT command is sent to the UICC 
(assuming that ISO/IEC 14443-4 [4] compliancy was indicated in the SAK) 

NOTE 2: For protocols according to ISO/IEC 18092 [8] 106 kbps passive mode, the command code 'D4' 
(ATR_REQ) recognized in the P'^ byte is treated in a similar way. 

NOTE 3: ISO/IEC 14443-3 [3] Type A permits the presence of both ISO/IEC 14443-4 [4] and proprietary RF 

protocols at one physical card. The type selection is done by the PCD evaluating the SAK byte sent from 
the PICC. As a future option, the ISO/IEC 14443-4 [4] processing may also take place on the UICC. In 
this case, the RATS command may be sent to the UICC encapsulated in the CL_PROTO_INF. 

• If the first byte is not equal to one of the above mentioned values, then the CLE shall compose a CLT frame 
with "CL_PROTO_INF" (A) in the ADMIN_FIELD and attaches the received RF data as DATA_FIELD. 
The EDC may be included. 

If the length of the RF data exceeds the D ATA_FIELD, this shall be treated as an RF error and no CLT 
frame shall be sent to the UICC. The CLE shall handle the error according to ISO/IEC 14443-3 [3] and 
ISO/IEC 14443-4 [4]. 

• After having sent CL_PROTO_INF, the CLE shall keep listening to the SWIO and shall not respond to RF 
interface activity, unless the RF field disappeared. 

Following actions shall be taken by the UICC on receiving the CL_PROTO_INF(A) CLT frame: 

• CL_PROTO_INF is the first frame of a CLT session. The UICC shall continue in CLT protocol operation. 

• The contents of the D ATA_FIELD shall be evaluated. If the RF data match with one of the RF protocols 
supported, the response shall be calculated and sent to the CLE. Otherwise, the CLE shall be triggered to treat 
it as an error by sending an appropriate CLT frame CL_GOTO_INIT. 

11.5.3.2 CL_PROTOJNF(F) 

With this ADMIN command, the CLF informs the UICC about the presence of a ISO/IEC 18092 [8] based RF protocol 
in 212 kbps/424 kbps passive mode, for which the anticollision is processed in the UICC. The anticollision commands 
shall be exchanged in CLT mode. 

CL_PROTO_INF(F) shall be sent by the CLF to the UICC after every detection of a new RF field according to 
ISO/IEC 18092 [8] for 212/424kbps passive mode if the CLF is configured to do so. This information is retrieved from 
higher application layers. 

Following actions shall be taken by the CLF for this ADMIN command: 

• When the CLF has received the POLLING REQUEST command (Command Code '00'), it: 

Shall start a timer in order to be able to align the response to the time grid; 

Shall memorize the Time Slot Number (TSN, 5^ byte of POLLING REQUEST payload); and 

Shall forward the command to the UICC encapsulated as payload in the CL_PROTO_INF(F) CLT 
frame. 

• The CLF shall send out the received POLLING RESPONSE according to the anticollision time grid as defined 
in ISO/IEC 18092 [8] for 212/424kbps passive mode. The CLF shall randomly select one of the available 
timeslot indicated as Time Slot Number within the previous POLLING_REQUEST. 
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NOTE: According to ISO/IEC 18092 [8], the POLLING RESPONSE is received by the Target after a waiting 
time of 2.417 ms (512 x 64 / 13,56 MHz) within one of the allowed time slot. Each time slot has a 
duration of 1.208 ms (256 x 64 / 13,56 MHz). 

Following actions shall be taken by the UlCC on receiving the CL_PR0T0_1NF(F) CLT frame: 

• CL_PROTO_lNF is the first frame of a CLT session. The UICC shall continue in CLT protocol operation. 

• The contents of the DATA_F1ELD shall be evaluated and the ISO/lEC 18092 [8] 212 kbps/424 kbps passive 
mode EDC and length (LEN byte) shall be verified. 

In case the received command does not match with the applications available on the UICC, the UICC 
shall send a CLT frame with an empty DATA_FIELD to the CLE within 850 |as. 

In case the command matches the application available on the UICC, the UICC shall respond with an 
CLT frame containing the ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode POLLING RESPONSE 
in the DATA_FIELD within 850 |is. 

In case an error with respect to ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode is detected, the 
UICC shall send a CLT frame with an empty DATA_FIELD to the CLE within 850 |is. 

Figure 1 1.3 shows a CLT frame containing an ISO/IEC 18092 [8] 212 kbps/424 kbps passive mode based frame. 



CLT 



ADMIN 



18092 data 



SOF 



1 



10 1 



Command + data 18092-CRC 



SWP-CRC EOF 





18092 frame (212 kbps and 424 kbps) 




Preamble SYNC 


LEN CMDO CMD1 Byte Byte 1 ... Byte n 


E2 (CRC) 



Figure 11.3: Type F structured CLT frame 

Figure 11.4 shows the byte alignment of ISO/IEC 18092 [8] based frame data within a CLT LPDU. 

Reception of ISO/IEC 18092 [81 212/424 kbps passive mode based frame via RF: 

L Byte 1-6 — L Byte 7-8 — I Byte 9 1 Byte 10 1 Byte 11 1 



Byte 12 



MSB 



LSB MSB 



LSB MSB 



LSB MSB 



LSB 



Preamble 


SYNC 


Data-Byte 1 


Data-Byte 2 


Data-Byte 3 


Data-Byte 4 



CLT LPDU via SWP in "ISO/IEC 18092 [81 212/424 kbps passive mode based frame" structured: 

I Bytel 1 Byte2 1 Byte3 1 Byte4 1- 
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Bytes 



b1 (LSB) b8 



b1 b8 



b1 b8 



b1 b8 



b1 
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Data-Byte 1 Data-Byte 2 Data-Byte 3 Data-Byte 4 

Figure 11.4: Type F byte alignment in CLT frame 
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11.5.3.3 



CL GOTO INITandCL GOTO HALT 



With those ADMIN_FIELD contents, the UICC shall informs the CLF about a necessary transition to initialization 
state with respect to the initialization state diagram on RF side. This may occur either in case of an error or if a 
dedicated transition command (e.g. HLTA) was decoded by the UICC. 

In ISO/IEC 14443-3 [3] Type A, the CLF has to support two initialization branches, the corresponding actions are 
outlined in table 1 1 .4. 

Table 11.4: Reasons and actions for CL GOTO INITandCL GOTO HALT 





The CLF was selected from IDLE state 
(via "READY/ ACTIVE" states) 


The CLF was selected from HALT state 
(via "READY*/ ACTIVE*" states) 


The UICC decodes an error 
-» send CL GOTO INIT 


Transition of tine CLF to 
ISO/IEC 14443-3 [3] "IDLE" state 


Transition of the CLF to 
ISO/IEC 14443-3 [3] "HALT" state 


The UICC decodes a HLTA 

command 
^ send CL GOTO HALT 


Transition of the CLF to 
ISO/IEC 14443-3 [3] "HALT' state 


Transition of the CLF to 
IS0/IEC1 4443-3 [3] "HALT" state 



11.6 CLT Protocol Rules 

11.6.1 Rules for the CLF 

The following rules apply for the CLF: 

• The CLF shall not issue a CLT command as long as there is an SHDLC frame transfer pending. 

• To open a CLT session, the CLF shall send a CLT frame with ADMIN_FIELD set to "CL_PROTO_INF". 

• Any SHDLC command may be received at any time (which closes the CLT session inherently) and shall be 
processed as intended. 

• During a CLT session, an incorrectly received SWP frame shall be ignored. To avoid a deadlock situation, the 
CLF shall enter the initial state of the RF anticollision and selection sequence and shall issue an appropriate 
higher layer command to the UICC or deactivate SWP after at least 10 ms. The same timeout mechanism shall 
apply in case the UICC has not responded to a CLT frame within 10 ms. 

11.6.2 Rules for the UICC 

The following rules apply for the UICC: 

• The UICC shall not send a CLT response before having received a CLT command. 

• Any valid CLT command shall be responded to with a valid CLT response. 

• Any SHDLC command may be received any time (which closes the CLT session inherently) and shall be 
processed as intended. 

• During a CLT session, an incorrectly received SWP frame (wrong CRC) or an unknown or erroneous CLT 
command shall be ignored. 
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12 Timing and performance 
12.1 SHDLC Data transmission mode 

When in SHDLC mode as defined in clause 10 the CLF shall be able to send multiple data frames over the SWP link to 
the UICC, the format and management of this data is out of the scope of this specification. The CLF shall transmit 
frames to the UICC in a timely fashion and shall ensure that the time from receipt of the last RF bit to the end of the 
transmission of the last SWP frame shall be less than T^^p ^^^^^ = 500 us. 



Where: 



and 



the last RF bit is the end of the last pause transmitted by the PCD 
(see ISO/IEC 14443-3 [3], appHes for Type A); 



the end of the transmission of the last SWP frame is the end of the last bit of EOF on signal SI. 

When receiving response data from the UICC the CLF shall be capable of concatenating multiple frames into a single 
RF transmission and shall ensure that the time between the first bit of the first frame over SWP to the start of the first 
bit of RF data shall be less than Tqu; s^dic - 500us. 



Where: 



ihQ first bit of the first frame over SWP is the start of the first bit of the SOF on signal S2; 



and 



the start of the first bit of RF data is the first modulation edge within the start bit 
(see ISO/IEC 14443-3 [3], appHes for Type A). 

NOTE 1 : The CLF and UICC must take care to ensure that no delays in SWP data cause a break in RF 
transmission. 

NOTE 2: The above timings presume error free communications over SWP 
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Figure 12.5: SHDLC transmission timings 
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1 2.2 CLT data transmission mode 

1 2.2.1 CLF processing delay when receiving data from tlie PCD 

The CLF receives RF data and sends data over SWP to the UICC. The processing delay by the CLF is defined as: 

The time between receipt of the last bit of the RF data block and last data bit sent over SWP 
where: 

the last bit of the RF data block is the end of last pause transmitted by the PCD 
(see ISO/IEC 14443-3 [3], appHes for Type A); 

and 

the last data bit sent over SWP is the end of the last bit of EOF on signal S 1 . 

This processing delay is designated as Tj-^^p receive- 

The CLF shall deliver the received RF data block as payload within exactly one CLT frame. In the case where the 
incoming RF data block exceeds the length limit of CLT, an error on the RF side or wrong RF protocol type shall be 
assumed and proper error handling shall be executed (see note 1). 

NOTE 1 : If the length of the incoming RF data exceeds the maximum length of the CLT payload, then the CLF 
may send to the UICC either an incorrect CRC or an incorrect EOF or an empty CLT frame. 

NOTE 2: The CLF may start data transmission over SWP after having received a complete RF data block or may 
start data transmission over SWP while still receiving RF data (pipelining). 

1 2.2.2 CLF processing delay when sending data to the PCD 

The CLF receives data over SWP from the UICC and modulates it onto the RF. The processing delay by the CLF is 
defined as: 

The time between the receipt of the first bit sent over SWP and the first bit sent to the PCD. 

Where: 

the first bit sent over SWP is the start of the first bit of the SOF on signal S2; 

and 

the first bit sent to the PCD is the first modulation edge within the start bit 
(see ISO/IEC 14443-3 [3], apphes for Type A). 

In the case where the RF protocol specifies that no response be sent to the PCD for a command, the processing delay by 
the CLF is defined as the time between the receipt of first bit sent over SWP from UICC to CLF and the time when the 
CLF shall be ready to receive the start bit of the next RF data block. 

This processing delay is designated as Tqu; transmit- 

The UICC shall deliver the RF data block as payload within exactly one CLT frame. The CLF shall deliver the received 
CLT payload within exactly one RF data block. 

The CLF shall check the ADMIN_FIELD for CL_GOTO_INIT, CL_GOTO_HALT, "Payload contains data" and 
"RFU" (as in the current document). The CLF shall then proceed as follows: 

• if the CLF has detected an CL_GOTO_INIT or CL_GOTO_HALT, the CLF shall evaluate the CRC of the 
SWP frame and follow rules given in clause 11. 6.1 (last bullet point); 

• if the CLF has detected "Payload contains data" 0000, then the CLF may start sending data after having 
received a complete CLT frame or may start sending data to the PCD while still receiving data over SWP 
(pipelining). If the CRC is not correct, the CLF shall follow the rules given in clause 11.6.1 (last bullet point). 
In case of non-pipelining and if the CRC is not correct, the CLF shall not modulate the RF-field; 
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• if the CLF has detected an "RFU" value, the CLF shall behave according to the rules given in clause 11.6.1 
(last bullet point). 

1 2.2.3 Timing values for tine CLF processing delay 

The total processing delay in the CLF is given by: 

T = T + T 

CLF,delay CLF.receive CLF.transmit 

The maximum values for both Tq^^ receive ^^'^ ^CLF transmit ^^ calculated as: 

T"cLF,receive = 100 ps + (15 |js per byte of RF data) 

TcLF, transmit =100|js + (15|js per byte of RF data) 
This gives a maximum value of 100 + (29 x 15) [is = 535 [is. 




SWP CLF - UICC 



TCLF,transmit 



SWP UICC - CLF 



UICC Processing 
time 



RF CLF- PCD 



NOTE: SWP CLF-UICC and SWP U/CC-CZ-F represent the time taken to transmit the data over SWP and are 
included in the TcLp.receive and TcLF,,ransmit tinges. 

Figure 12.6: CLF transmission timings 

The CLF and UICC should take care to ensure that processing delays do not comprise overall transactions times of 
commands and ensure that response timeslots can be achieved. 

NOTE: In the diagram above TPICC represents a time equivalent to the total processing time of a Contactless 

card and is used to demonstrate the relationship between a card emulated by a CLF/UICC pair and a real 
card. 

Using the above diagram and the example of a typical ISO/IEC 14443 type A read command where the 
command from the PCD is 2 bytes long plus a CRC and the response is 16 bytes long plus a CRC then we 
would see: 



CLF,receive " 



160 |js 



CLF,transmit ' 



370 us 



TPICC =160 |js + 370 |js = 530 |js plus the processing time of the UICC 
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1 2.2.4 Timing value for tine CLF processing delay (Request Guard Time) 

If the CLF receives from the PCD a REQA or WUPA, the Request Guard Time (ISO/IEC 14443-3 [3]) has to be 
respected. The maximum value for T^^f delay ^^'■ 

T(max)cLF,delay=180^S 

NOTE: UICC and a CLF operating in CLT may be in the states ACTIVE or ACTIVE* (named as PlCC states in 
ISO/lEC 14443-3 [3]). A REQA/WUPA sent by the PCD will force a transition to the PlCC states IDLE 
or HALT (with no response from the CLF to the PCD). A subsequent REQA/WUPA will restart the 
collision resolution process. In some implementations, the PCD deliberately forces this error condition in 
order to exit the authenticated state of the PlCC. 
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Annex A (informative): 

CLT Protocol Operation flowcharts 

The followings flowcharts are given for typical Use Cases. 



A.1 Example Flowchart for the UICC 
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Figure A.I 
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A.2 Example Flowchart for the CLF 

This example contains details for ISO/IEC 14443-3 [3] Type A based RF protocol initialization. 
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Figure A.2 
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